The author of this tool uploaded a YouTube video demonstrating it a few days ago: https://www.youtube.com/watch?v=15_-hgsX2V0
At one point in his demo, he uploads a file but terminates the upload more or less halfway. Then he begins downloading the file - which only progresses to the point it had been uploaded, and subsequently stalls indefinitely. And, finally, he finishes uploading the file (which gracefully resumes) and the file download (which is still running) seamlessly completes.
I found that particularly impressive.
Celebrate 100 years since complete ipv6 adoption.
Basically every new law, piece of news or media I see coming from the UK paints a picture of a beat-down, cynical & scared society that's complacent to or in support of increasing surveillance and control by the government. Like maybe Adolescence or basically any mention of the NHS. The crimes they cite like child grooming or terrorism/hate being incited sound pretty terrible too, but I wonder why the UK specifically is taking action - is the issue bigger there, or are they just more aware of and willing to act on it.
In the case of Android, genuine means:
The operating system was licensed by Google
The app was downloaded from the Play Store (thus requiring a Google account)
Device security checks have passed
The issue is being raised here: https://github.com/eu-digital-identity-wallet/av-app-android...
I would like to strongly urge to abandon this plan.
Requiring a dependency on American tech giants for age verification
further deepens the EU's dependency on America and the USA's
control over the internet.
Especially in the current political climate I hope I do not have
to explain how undesirable and dangerous that is.
There are a number of comments in that same thread that indicate a mandate to utilize Google services may run afoul of EU member nations' integrity and privacy laws.
I understand wanting to make the organization more efficient, but i don't think this is what's happening here. I think this is the classic republican strat of gutting federal agencies, pointing to the inefficiencies caused by the loss of institutional knowledge, and using that as an excuse to privatize to their friends.
The fact that Elon's DOGE suggested these cuts lines up
> In 1998, Yahoo turned down the opportunity to acquire Google for $1 million. Yahoo made six acquisitions that year, spending $107.3 million.
> In 2002, Google offered to sell again for $1 billion. Yahoo hesitated and Google raised its price to $3 billion. Yahoo declined at the higher price. Google went on to become a trillion dollar company.
> Yahoo attempted to acquire Facebook for $1 billion in 2006, but Mark Zuckerberg turned down the offer. Had Yahoo increased its offer by just $100 million, Facebook’s board would have forced Zuckerberg to take it. Facebook also became a trillion dollar company.
In inclined to believe that neither would have become trillion dollar companies if they had been acquired by Yahoo.
At AutoTempest we resisted making an app for years, because anything that a hypothetical app could do, we could do with the website. And in my opinion, when searching for cars, it's more convenient to be in your browser where you can easily open new tabs, bookmark results, etc.
And for years, it was our most requested feature, by far. We had instructions for how to pin the site to your home screen, and would explain to users how the website does everything an app can do. Still, constant requests for an app. Finally we relented and released one, and very quickly around half our mobile traffic moved to the app without us really trying to nudge people at all.
People just really like apps! I think it suits our mental model of different tools for different uses. We've also found that app users are much more engaged than website users, but of course much of that will be selection bias. Still, I can see how having your app on someone's home screen could provide a significant boost to retention, compared to a website they're liable to forget. For us now, that's the main benefit we see. Certainly don't use any additional data, though I won't argue that other companies don't.
I cannot agree more and this has always been a pet peeve of mine.
Most native apps are some half gig large where even the heaviest website is a few mb. They dont let you highlight text and have other bizarre design choices. Even worse, they request importing contacts list which isnt even an option on the web.
Native apps could be butter but more often than not they are like margarine. Smooth, oily, and not good for you.
SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.
Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolutely, if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.
But SPAs came about in the days of jQuery, not React. You'd have a complex app, and load up a giant pile of jQuery spaghetti, which would then treat each div of your app is its own little mini-app, with lots of small network requests keeping everything in sync. It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. jQuery made it feasible to do SPAs instead.
Later, React and other frameworks made it less spaghetti-like. And it really took off. Often, for sketchy reasons. But the strongest argument for SPAs remains using them as a solution to provide a single-load of a large code bundle, that can be cached, to provide minimal network traffic subsequent to the load when the expected session time of a user is long enough to be worth the trouble of the complexity of an SPA.
Engineers: always negotiate for higher base salaries. In the vast majority of cases—especially during acquihires—your equity will be worth little or nothing. Founders and VCs still get paid; employees rarely do.
Don't just accept promises. Ask for the 409A valuation, liquidation preferences, and pay bands. If a company won’t provide transparency, that’s your signal.
Equity is a lottery ticket. Salary is money in the bank.
Self-hosting isn't just about tech choices — it's about *who controls access to knowledge*.
During the Enlightenment, owning a physical copy of a book meant intellectual freedom. You didn’t rent ideas; you had them. Today, most digital knowledge is hosted, locked, or streamed — *leased from platforms*, not owned. We’re in fact drifting into *digital feudalism*, where access to culture, tools, and even history depends on gatekeepers.
In a perfect world this should go beyond market logic. It’s not just a question of what's sustainable or profitable. It's about *civic autonomy*. If the infrastructure of knowledge is centralized, then so is control over thought.
Self-hosting may not be for everyone, but *distributed, open systems are essential* to preserving a democratic and durable digital commons.
This story has been reposted many times, and I think GJS's remarks (as recorded by Andy Wingo) are super-interesting as always, but this is really not a great account of "why MIT switched from Scheme to Python."
Source: I worked with GJS (I also know Alexey and have met Andy Wingo), and I took 6.001, my current research still has us referring to SICP on a regular basis, and in 2006 Kaijen Hsiao and I were the TAs for what was basically the first offering of the class that quasi-replaced it (6.01) taught by Leslie Kaelbling, Hal Abelson, and Jacob White.
I would defer to lots of people who know the story better than me, but here's my understanding of the history. When the MIT EECS intro curriculum was redesigned in the 1980s, there was a theory that an EECS education should start with four "deep dives" into the four "languages of engineering." There were four 15-unit courses, each about one of these "languages":
- 6.001: Structure and Interpretation of Computer Programs (the "procedural" language, led by Abelson and Sussman)
- 6.002: Circuits and Electronics ("structural" language)
- 6.003: Signals and Systems ("functional" language)
- 6.004: Computation Structures ("architectural" language)
These were intellectually deep classes, although there was pain in them, and they weren't universally beloved. 6.001 wasn't really about Scheme; I think a lot of the point of using Scheme (as I understood it) is that the language is so minimalist and so beautiful that even this first intro course can be about fundamental concepts of computer science without getting distracted by the language. This intro sequence lasted until the mid-2000s, when enrollment in EECS ("Course 6") declined after the dot-com crash, and (as would be expected, and I think particularly worrisome) the enrollment drop was greater among demographic groups that EECS was eager to retain. My understanding circa 2005 is that there was a view that EECS had broadened in its applications, and that beginning the curriculum with four "deep dives" was offputting to students who might not be as sure that they wanted to pursue EECS and might not be aware of all the cool places they could go with that education (e.g. to robotics, graphics, biomedical applications, genomics, computer vision, NLP, systems, databases, visualization, networking, HCI, ...).
I wasn't in the room where these decisions were made, and I bet there were multiple motivations for these changes, but I understood that was part of the thinking. As a result, the EECS curriculum was redesigned circa 2005-7 to de-emphasize the four 15-unit "deep dives" and replace them with two 12-unit survey courses, each one a survey of a bunch of cool places that EECS could go. The "6.01" course (led by Kaelbling, Abelson, and White) was about robots, control, sensing, statistics, probabilistic inference, etc., and students did projects where the robot drove around a maze (starting from an unknown position) and sensed the walls with little sonar sensors and did Bayesian inference to figure out its structure and where it was. The "6.02" course was about communication, information, compression, networking, etc., and eventually the students were supposed to each get a software radio and build a Wi-Fi-like system (the software radios proved difficult and, much later, I helped make this an acoustic modem project).
The goal of these classes (as I understood) was to expose students to a broad range of all the cool stuff that EECS could do and to let them get there sooner (e.g. two classes instead of four) -- keep in mind this was in the wake of the dot-com crash when a lot of people were telling students that if they majored in computer science, they were going to end up programming for an insurance company at a cubicle farm before their job was inevitably outsourced to a low-cost-of-living country.
6.01 used Python, but in a very different way than 6.001 "used" Scheme -- my recollection is that the programming work in 6.01 (at least circa 2006) was minimal and was only to, e.g., implement short programs that drove the robot and averaged readings from its sonar sensors and made steering decisions or inferred the robot location. It was nothing like the big programming projects in 6.001 (the OOP virtual world, the metacircular evaluator, etc.).
So I don't think it really captures it to say that MIT "switched from Scheme to Python" -- I think the MIT EECS intro sequence switched from four deep-dive classes to two survey ones, and while the first "deep dive" course (6.001) had included a lot of programming, the first of the new survey courses only had students write pretty small programs (e.g. "drive the robot and maintain equal distance between the two walls") where the simplest thing was to use a scripting language where the small amount of necessary information can be taught by example. But it's not like the students learned Python in that class.
My (less present) understanding is that >a decade after this 2006-era curricular change, the department has largely deprecated the idea of an EECS core curriculum, and MIT CS undergrads now go through something closer to a conventional CS0/CS1 sequence, similar to other CS departments around the country (https://www.eecs.mit.edu/changes-to-6-100a-b-l/). But all of that is long after the change that Sussman and Wingo are talking about here.
About 60k academic citations about to die - https://scholar.google.com/scholar?start=90&q=%22https://goo...
Countless books with irrevocably broken references - https://www.google.com/search?q=%22://goo.gl%22&sca_upv=1&sc...
And for what? The cost of keeping a few TB online and a little bit of CPU power?
An absolute act of cultural vandalism.
I just installed Graphene on a new pixel. I've only used it for two days, but I got that same feeling of "finding buried treasure in your backyard" I got when I first installed Linux in 1999. I can't believe this amazing software is free in all senses of the word. It is a TON of work and they got so much right. The security and usability settings give all the grainular control I've known was possible and wanted for a long time.
I see some core team on this thread, so just wanted to say THANK YOU! Awesome job! Keep fighting for the users!
I'm totally the wrong person to offer recommendations on mobile, but so far it works very well for me, but then, I use almost no third party apps, and none of them are Play store only. My only complaint is the hardware (outside of their control).
Brazil central bank introduced Pix a few years ago. It took over the country as the public basic infrastructure for money transfer. Totally free and instantaneous transactions between people and companies, available to all banks.
Then, just last week, the US presidency launched an investigation considering Pix an unfair trade practice against the US.
Actions like that may show the current direction of the US government is aligned on preserving status quo. But still, I wonder how impactful a public digital infrastructure for the dollar would be.
If that is the cost of keeping the value within the western economies, we should pay. Plain and simple. I'd even argue it's cheap.
Downloaded the app and paid for premium. Still no wife. Devs pls fix.
This is a deeply concerning development, though not an entirely surprising one. While I sympathize with itch.io's position - being caught between their creators and their payment processors - the broader implications here are alarming.
Payment processors have effectively become unelected censorship boards with the power to strangle entire categories of legal content by threatening to cut off the economic infrastructure that platforms depend on. The fact that a single advocacy campaign can pressure Visa/Mastercard/PayPal into forcing platforms to remove legal adult content should concern anyone who values free expression online.
The fundamental issue isn't whether you personally approve of adult games or specific content - it's that a handful of payment companies now wield veto power over what legal content can exist in the digital economy. This represents a massive concentration of censorial authority in the hands of unaccountable corporate entities that face no meaningful democratic oversight.
We've seen this pattern repeatedly: PayPal blocking VPN providers over "piracy concerns," Visa suspending payments to adult sites, and now this coordinated pressure campaign. Each time, legal content gets effectively banned not through legislation or courts, but through corporate policy decisions made behind closed doors.
By inserting themselves as moral arbiters for the digital economy and free expression on the internet, these processors are creating a very strong case for being designated as common carriers or being subjected to much stricter public utility regulation. When payment infrastructure becomes as essential as electricity or telephone service for participating in the digital economy, treating these companies as neutral utilities rather than editorial boards becomes not just reasonable but necessary.
This is great.
I set it up and was conspicuously swiping in bed. My wife is all hey, what are you doing? I’m all nothing.. put the phone down on the dresser.
No, let me see your phone etc. I relent, she opens the app with sulphur smoldering in her nostrils lol, then she starts poking around, and we have been having a really great night since.
Here is the experience when clicking a link on mobile:
* Page loads, immediately when I start scrolling and reading a popup trying to get tracking consent
* If I am lucky, there is a "necessary only". When unlucky I need to click "manage options" and first see how to reject all tracking
* There is a sticky banner on top/bottom taking 20-30% of my screen upselling me a subscription or asking me to install their app. Upon pressing the tiny X in the corner it takes 1-2 seconds to close or multiple presses as I am either missing the x or because there is a network roundtrip
* I scroll down a screen and get a popup overlay asking me to signup for their service or newsleter, again messing with the x to close
* video or other flashy adds in the content keep bugging me
This is btw. usually all before I even established if the content is what I was looking for, or is at any way useful to me (often it is not).
If you use AI or Kagi summarizr, you get ad-free, well-formatted content without any annoyance.
GrapheneOS says
"European authoritarians and their enablers in the media are misrepresenting GrapheneOS and even Pixel phones as if they're something for criminals. GrapheneOS is opposed to the mass surveillance police state these people want to impose on everyone"
https://grapheneos.social/@GrapheneOS/114784469162979608
State employees in their official capacity making inaccurate claims to media about GrapheneOS to smear it as being for criminals and as the users as largely being criminals is a state sponsored attack on the GrapheneOS project.
https://grapheneos.social/@GrapheneOS/114813613250805804